PsL Monthly 1993 December

home *** CD-ROM | disk | FTP | other *** search

/ PsL Monthly 1993 December / PSL Monthly Shareware CD-ROM (December 1993).iso / prgmming / dos / tools / betatst.exe / README.DOC < prev next >

Wrap

Text File | 1993-04-21 | 29.7 KB | 1,062 lines

BETA TESTERS MANUAL <* your software company name here *> Phone : (###) ###-#### BBS (###) ###-#### Protocol is 9600, N, 8, 1 available 24 hours. FAX (###) ###-#### ADDRESS : ##################### ##################### ##################### <* NOTE: If No Fax Remove Fax Reference On This Page, Contents, And In Manual *> Overview............................................. 3 Testing.............................................. 4 Alpha Testing.................................. 4 Beta Testing................................... 4 What Beta Testing is Not....................... 4 Documentation.................................. 5 Beta Material.................................. 5 Communications....................................... 6 Phone.......................................... 6 BBS........................................... 6 Fax............................................ 6 Not finding any Problems? (IMPORTANT).......... 6 Using the Beta Report Generator...................... 7 Problem Report Format................................ 9 Using the Bulletin Board............................ 10 General Information........................... 10 Uploading Reports............................. 10 Downloading Files............................. 10 Bulletin...................................... 10 Beta Evaluation..................................... 11 End of Beta......................................... 12 On going support.............................. 12 Beta testing future releases.................. 12 Appendix 1 - Testing Ideas......................... 13 Appendix 2 - Sample: Problem Report................ 14 Appendix 3 - Problem Solving Techniques............ 17 Appendix 4 - Trouble Shooting Tips................. 18 OVERVIEW We have designed these beta procedures, to inform you of how to use the BETARPT program. In addition, we will outline the reporting procedures when problems have been found in application software. Our overall goal is to achieve a streamlined method of reporting application bugs and making timely corrections. We understand the time constraints and pressures that our beta testers are under. We hope that you also realize that we are under timely pressures as well. There will be times when beta tests will be pushed back to a later date or given less testing time. We intend to do our best to prevent this from happening. We want you to enjoy testing our products while providing us with your input. We will try our best to follow the procedures outlined. As beta testing develops and changes, so will the procedures. We will provide you with updates of the beta report generator and policies manual as appropriate. We will always welcome any ideas that you have that will strengthen the communication's channel. Please contact us if there is something that you do not understand. Please remember it is a time-consuming task to track all the problems that beta testers report. If we have trouble recreating your reported problem, we may ask you for additional information. The following outlined procedures should keep communications open and all beta testing aspects tied together. 3 TESTING Alpha Testing The alpha testing phase of the application is done by us using in-house testers before the application goes to outside beta testers. Alpha testing is designed to make sure that all features of the product work with other hardware and software that we have available. When all the major problems have been found, we then select beta sites to send the product to for additional testing. Beta Testing In beta testing we ask the beta testers to use, as closely as possible, the application in real world situations. Because of this approach we have found beta testers provide more variety of testing to catch cosmetic flaws, compatibility problems, and other peculiarities about the application. Beta testers use the software and report anything that is not described by the manual, or seems to function improperly. Please keep in mind that no beta software is problem-free. If you have important information on your machine that cannot be lost, it is to your advantage to make a backup before testing the product. WARNING: BE SURE TO HAVE CURRENT BACKUPS OF YOUR DATA. What Beta Testing is Not Beta testing is not a phase for redesigning the application. The primary purpose of beta testing is to find problems the way the program presently stands. We are always willing to listen to our customers and will gladly take your comments and suggestions, but please understand, more than likely, unless there is an extreme demand for change, you will not see any suggestions implemented until a future release. 4 Documentation While going through the application documentation, please let us know about any inconsistencies that you find when possible. As a guideline, we need to know about flaws in the documentation within two weeks after you download the beta material. We do not want to restrict your comments to this period, but comments need to be processed immediately. All your manual comments or suggestions can be put into one report. Beta Material Beta test updates are available by calling the BBS. Under extreme cases we may ship beta material to the latest address that you have provided. In most cases only the files with bugs will be available as updates. 5 COMMUNICATIONS Phone We use the BBS almost exclusively for the distribution of beta test software. Previously, we used to take beta reports over the phone, however; it turned out to be less than organized. If you have a problem that needs to be resolved by phone, please leave us a message and we will call you. Bulletin Board The Bulletin Board is our primary source of communication. The number is listed on the cover of the Beta Tester's manual. The BBS protocol is also listed on the cover of the Beta Tester's manual. Prior to receiving this beta procedures manual you should have selected a user name/ID and password. If this did not occur contact us with your selection. Fax We have a Fax number for your convenience. Please use this only if there is some kind of problem with the BBS. The exception is if you have material that is better off being faxed such as manual comments and suggestions. The number is listed on the front page of the manual. Not finding any problems Sometimes especially in the final stages of the beta test its difficult to find problems. If you feel that you are not finding any problems, refer to Appendix 1. This appendix should give you some basic ideas on finding those difficult problems. If you are still unable to find any problems please contact us by submitting a report and let us know what you did test and the outcome. Keeping in contact with us is how we figure out who will be included in future beta tests. 6 USING THE BETA REPORT GENERATOR Make a directory called BETA. This is a directory for you to store the beta report program and its report files. To run the report program type BETARPT at the DOS prompt. Once the program is loaded the main menu will appear allowing you to make your selections. The first time that you run the BETARPT program you will immediately enter the program and user information section. Subsequent accesses to BETARPT will not make you go through these two steps. Selections are made by pressing the various highlighted function 'F' keys. The following 'F' keys are available: F1 - Help F2 - Program Information F3 - Tester Information F4 - Problem Description F5 - Corrective Action F6 - DOS Shell F7 - Program Recommendation F8 - Special Developer Info. F9 - Save Temp Files & Exit F10 - Create Report By making any one of the above selections you will be transferred to that section. Once transferred a status line is provided to offer simply instructions. Context sensitive help is provided by pressing the 'F1' key anytime. The information below provides a brief explanation of each of the areas within the BETARPT program. a. By pressing the 'F2' key you are asked to provide bug information about the application you are presently testing. You are asked to be very specific so we may use this information to attempt to reproduce the bug. b. The 'F3' key will gain useful information about the system you are using to test the beta application. Please fill out all lines as accurately as possible. c. To describe the bug problem press 'F4'. Please be in-depth while being brief. d. The 'F5' key is used to tell us what actions you took to attempt to correct the noted bug. This includes but is not limited to removing the AUTOEXEC.BAT and CONFIG.SYS files. 7 e. A DOS shell is provided by pressing the 'F6' key. f. The 'F7' is provided so you may included specific recommendations for future releases of the product. g. In some testing applications the 'F8' will be available to you. If the Special Developer Info. is not available if will be a different color than the rest of the selections. If the 'F8' key is available simply answer all the questions as you did in the Tester Information area and Program Information area. h. Pressing 'F9' will save all current files and exit to DOS. This is useful when you wish to research a particular bug more thoroughly and do not wish to create a new bug report. 6. To create a report press the 'F10' key. Once you have created a report, the Beta Report program will create a file called BETA.RPT. The BETA.RPT file will contain both the report that you just created and the status of your machine at the time you wrote the report. This is the file that we need to have uploaded to us. Once you have written your second report, the report program will rename your first report to BETA.1. The same situation will happen for your third report, where BETA.RPT will be renamed to BETA.2, etc. The most current report will always be named BETA.RPT. 7. When you upload your reports to the BBS, they must be send as a message to the Sysop or as directed at that time. You will have to upload the BETA.RPT file in ASCII format. WARNING : DO NOT COMPRESS YOUR REPORTS IN ANY WAY!! Upload in an ASCII format only to the message base. 8 PROBLEM REPORT FORMAT The following tid bits of information are what we would like to see in the bug problem reports that you will submit. If you give this type of information when reporting a problem, we should be more than likely to duplicate the error and not have a need to call you. 1. Run the BETARPT.EXE program and fill it out all areas that apply entirely. 2. Describe the problem with a short sentence as complete as possible. Then if applicable give a keystroke description of how to reproduce the problem. See Appendix 2 for an example. Read over your report to be certain it clearly describes the problem, keeping in mind that we will have to recreate what you submitted. 3. In narrowing down the problem refer to the problem-solving techniques listed in Appendix 3. By using these techniques it should help to eliminate possible conflicts that may be created by TSRs or other nonessential drivers or programs while testing the application. 9 USING THE BULLETIN BOARD General Information The bulletin board is used as the main method of information exchange between us and the beta tester. We ask that you check the bulletin board regularly for any new information regarding upcoming beta tests, or information on current tests. Uploading Reports The beta report upload is simple and we require ALL reports to be submitted to the message base in ASCII format. Any attempt to compress the files will result in loss of important bug information. Downloading Files Generally, the BBS only maintains applications presently being tested or individual files of maintenance releases. When a new file is available for downloading you will be advised of this via your message box. Please download the file(s) immediately and delete the message. Bulletin On the BBS we have a bulletin that is updated weekly, unless there is no new information. Please read it occasionally as it contains important information concerning the status of beta testing. 10 BETA EVALUATION During the beta test period, we will be evaluating each tester based on their participation! If we do not hear from you during the beta test, you will then be withdrawn from future beta testing. If you had indicated a preference for testing other products your name will be removed from those list as well. The point is please keep in communication with us at all time. It is a challenge to manage a beta test and we ask for your support. 11 END OF BETA Beta testers who successfully complete the beta test will, if possible, receive the final product. Additionally, they will be notified of the testing conclusion that will generally be posted on the BBS for a couple of weeks. We consider successful completion of the beta test means that the tester has found at least 2 or 3 bugs a week and was active throughout the beta period. On going support After the beta period has ended, all questions can be directed to the Technical Support Department. Beta testing future releases We will always be looking for future testers because the software will constantly be revised and upgraded to meet our users' demands. Beta testers who are active in finding problems, give clear, concise reports and follow these procedures will be given the opportunity to test future releases. 12 APPENDIX 1 Testing Ideas 1. Test the interface-checking of each button, Function keys, Quick keys, menu selections, and mouse functionality. 2. Test the on-line and manual help. Refer to the beta applications README file or manual for where to go to get help information. 3. Verify all program parameters or command line options. 4. Read the manual and test the described functionality. 5. Test the different configuration options. 6. Review the beta manual for errors and inconsistencies with the program. 7. If possible, use the program in your everyday environment. 13 APPENDIX 2 Sample Problem Report BETA TEST REPORT MyLife Software Report Created : 12-22-1992 Time : 22:51:52 Report Submission Number: 4 ----- TESTER INFORMATION: ----- Name : John Sanders Address : 704 Rim Drive City, State, and Zip : Killeen, Tx 76542 Home Phone : (817)634-8569 Home Phone Can Call : X Work Phone : (817)634-3043 Work Phone Can Call : Fax Phone : (817)628-2017 System Type : 80386 System Make : Genesis System BIOS : AMI System BIOS Date : 09/10/90 System Memory : 8 meg System Memory Manager : Qemm v6.01 'A' Floppy Drive Size : 5.25HD 'B' Floppy Drive Size : 3.5 HD Harddrive Size : 210 meg Harddrive Type : Seagate, IDE Monitor Type : SVGA Monitor Maker : Ultra VGA Monitor Card Maker : Ultra, 1Meg Operating System : DOS V5.0 File Compression : Stacker v2.0 with card Modem : X Modem Type : Mx Modem, 2400 Baud Mouse : X Mouse Type : Prohance, Tracball Fax : Fax Type : Scanner : X Scanner Type : The Complete, B&W Scanner Other : X Other Type : Arcnet Card ----- PROGRAM INFORMATION: ----- Application Name : Decide, V2.0 Program Name : DECIDE .EXE 14 Program File Size : 64325 bytes Program File Creation Date : 10/02/92 Program File Creation Time : 12:34 Tried Without AUTOEXEC.BAT : X Tried Without CONFIG.SYS : X Occurs in Windows : X Occurs in OS/2 : Occurs : Sometimes General Bug Description : The mouse does not function properly. ----- PROBLEM DESCRIPTION: ----- When accessing certain menu areas the mouse will disappear. I access a different menu area and return to the main menu and the mouse will not appear. I have to exit the program in order to get the mouse to reappear. ----- CORRECTIVE ACTION: ----- I tried removing the Tracball driver and tried several other drivers. I also attempted to use a Microsoft compatible mouse. ----- APPLICATION RECOMMENDATION: ----- ----- AUTOEXEC.BAT file: ----- SET COMSPEC=C:\DOS\COMMAND.COM C:\QEMM\LOADHI /R:1 C:\DOS\APPEND=C:\DOS COPY C:\DOS\COMMAND.COM C:\>NUL PROMPT $e[1;44;37m*$e[0m$e[41m▀▀▀$e[0m $p$g C:\QEMM\LOADHI /R:1 C:\QEMM\BUFFERS=50 C:\QEMM\LOADHI /R:1 C:\DOS\EMMOUSE C:\QEMM\LOADHI /R:1 C:\DOS\MOUSE SET PCTOOLS=D:\PCTOOLS\DATA SET TEMP=C:\WINDOWS\TEMP SET LIB=D:\BC7\LIB SET OBJ=D:\PROBAS\OBJ SET GMKW=D:\GMKW\ SET COMMUTE=D:\COMMUTE\DATA PATH=C:\QEMM;C:\DOS;C:\WINDOWS;C:\STACKER;D:\GMKW;D;\CALERA\BIN MIRROR C: D: E: ----- CONFIG.SYS file: ----- DEVICE=C:\QEMM\QEMM386.SYS R:1 EXCLUDE=B000-BA00 RAM ST:M DOS = HIGH SHELL=C:\DOS\COMMAND.COM C:\ /E:512 /P DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos\ansi.sys DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos\setver.exe FILES = 50 15 BUFFERS = 1 DEVICE=C:\QEMM\LOADHI.SYS /R:1 D:\CALERA\CPCSCAN.SYS 3e0 2 1 DEVICE=C:\QEMM\LOADHI.SYS /R:1 C:\STACKER\STACKER.COM C:\STACVOL.000 ------------------------ END OF REPORT ------------------------ This is an example of a simple problem report. We realize that some problems you may encounter will need to be narrowed down, but since we have a good step-by-step description we also should be able to recreate it. Any information you provide about the problem will be very helpful. If the example information is supplied, there should be no cause for more information, unless we simply cannot recreate the described situation. Keep a copy of your reports for testing updated versions of the product. 16 APPENDIX 3 Problem Solving Techniques To narrow down a problem you will need to troubleshoot it. Here are a few suggestions to get you started. 1. Can the problem be duplicated consistently? 2. Are you running with any memory resident(TSR's) programs? If so, try running without them. Does the problem still exist? 3. Try rebooting your machine without the AUTOEXEC.BAT and CONFIG.SYS. Does the problem go away? If yes, use a process of elimination to find the compatibility problem. (Add CONFIG.SYS and test, then add AUTOEXEC.BAT and test, etc.) 4. If the application is small enough try using it on another computer. Does the problem occur on another computer? If not, what is the DOS and BIOS version and date of the problem computer? 5. Do you have all the necessary files to run the program? Try reinstalling the program and retest it again. 6. Did the bug occur in an earlier beta version? 7. Could the files be sitting on a bad sector? Copy all program files to another subdirectory and try again. These are merely suggestions to help in the debugging process. If, after trying these suggestions you are still not sure what to do, let us know what you have tried and what the outcome was. Once in while you may find a problem that occurs very infrequently, go ahead and report it. If several people report the same thing we may be able to find a pattern. 17 APPENDIX 4 Trouble Shooting Tips Listed below are several items that may help you in trouble shooting problems with our beta applications: a. Boot from the 'A' drive and a clean system. If the problem does not exist then use the process of elimination to determine the cause. b. Check for multiple copies or versions of 'COMMAND.COM' on your drive(s). Remove any that are not used. c. Reinstall the application on/in a different subdirectory or drive. If the application works correctly then old files are either corrupt or the files were sitting on a bad sector of the disk. d. Use all command line options. e. Change the selected video mode. f. Ensure all cables are correctly secured. g. Ensure all computer circuit cards are correctly installed. h. Check all memory chips. i. Check for interrupt conflicts. It is possible that 2 or more boards or ports are occupying the same interrupt. j. Check that the interrupts you are using are set correctly for the device. Make such LPT1 is using IRQ 7, Comm 1 is using IRQ 4 and Comm 2 is using IRQ 3. k. Use the DOS program CHKDSK.exe to check the condition of the harddrive. It is possible you have lost clusters or a corrupted file allocation table. l. If you have a conflict with a memory manager such as QEMM or 386MAX try using command line options that control upper, expanded, and extended memory. m. Make sure that no memory conflicts exist. Some LAN cards require upper memory that is mapped by a memory manager. 18